Content management systems are used to organize, manipulate, and archive collections of content for organizations. In some cases, a content management system is developed in part by a customer. A content management system vendor provides general or underlying platforms, services, and/or objects referred to as a base product. The customer, or a developer hired by the customer, defines and develop products (e.g., custom applications) that run on or otherwise interact with the base product provided by a content management system vendor. The product(s) developed by a customer and the base product collectively form a content management system.
The portion of the content management system developed by a content management system vendor may affect the portion developed by a customer and vice versa. In some content management systems, a content item is represented within a body of managed content by one or more persistent software objects, sometimes referred to herein as “implementation objects”. The objects include metadata about and/or other attribute data associated with the content item, and in some cases its relationship to other content, and/or methods available to be performed with respect to the content item, such as check-in, check-out, save, versioning, etc.
In some systems, the vendor-supplied content management system includes a set of foundation classes for managing content. The foundation classes include classes for managing commonly encountered content items, such as documents, database files/tables, etc. However, a customer may desire to define one or more custom classes to manage specific content with specific content management requirements. In one example, the customer is a hospital that wants to store patient medical records, including by defining a record as a virtual or complex object to which other content items are related, e.g., lab results, health history, physician/nursing staff notes, etc. Such a customer may develop one or more custom classes of objects to represent patient medical records and related content. The custom class in some cases may be built based on a basic document or basic “record” class provided by the content management system vendor and/or defined previously as a custom class. Such a class typically is related to the base (parent) class in a hierarchy of classes on the content management system. In such a system, changes by the content management system vendor or another third party to one or more non-custom classes, such as a parent class of a custom class developed by a customer, and/or insertion of one or more new classes in the class hierarchy in a typical system would result in a need to recompile classes that depend directly or indirectly from the modified or new class(es). This may be inconvenient or annoying to a customer, potentially resulting in lost data, system downtime, etc., and in any event would require that there be a mechanism to inform the customer of the need to recompile custom classes. It would be useful to have a content management system in which changes affecting implementation class hierarchy would not require that affected classes be recompiled.